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Senrie* Prov*d»f » Server 
Payment Accounting System 

(57) Abstract: A system and method arc disclosed, see figure 1, for validating service bills including a first monitoring subsystem 
associated with and under the control of a service user (12). for determining user generated fee values associated with the amount 
due to a service entity for service usage over a predetermined billing period. A second monitoring subsystem communicating with 
the first monitoring subsystem is associated with and under the control of the service entity (13), for determining service generated 
fee values associated with the amount due the service entity for the usage over a predetermined billing period. One of the monitoring 
subsystems compares the user and service generated fee values and thereupon validates the amount due determined by one of the 
user and service generated fee values if such fee values arc within a predetermined threshold amount. 
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SYSTIiM AND METHOD FOR TRUSTED SHLF-BIMJNG I OR UTILITIES 

5 FIELD OF THE INVENTION 

The present invention relates generally to a system and method for 
paying utility bills, and more particularly to a system and method for paj'ing utility 
bills employing independent verification of the utility bill by the customer. 

10 BACKGROUND OF THE INVENTION 

Small and medium size business and households regularly pay utility 
bills, such as for telephone, Internet connection, electricity, gas and water services. 
The process of payment in the United States typically involves the user or customer 
examining the utility bill issued and sent (normally by mail) by a utility service 

15 provider or company (utility) for correctness and thereupon issuing and sending a 
check in a courtesy reply envelope to a remittance center of the utility company. 
The check is received, processed and sent to a clearing process at the end of which 
the amount of the check is transferred from the user's account in the user's bank to 
the utility's account in its bank. In European countries, utilities frequently enter into 

20 an agreement with their customers which allow them to deduct the amount of the 
bill directly from the customer's bank account. Customers typically have ten days 
after receipt of the notification to dispute the validity of the bill. In either case, 
however, the process frequently includes complex and costly dispute resolution 
concerning the amount owed the utility by the consumer. 

25 The cost of operating the utility payment system represents a 

significant portion of the total cost of operating the utility. The cost of operating the 
payment system is defined as combined cost incurred by the user (customer) and 
utility company in the process of accounting for the charges and the transfer of 
^payment from customer to the utility service provider. This cost has increased 

30 relative to other costs in the last twenty years, particularly in the telephone industry. 
The reason for the increase is that because of technological improvements all 
fundamental operations of the telephone network have been cost-reduced and 
streamlined while the payment system has essentially remained the same. 
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It is difficult to establish a "good" economically effective payment 
system. The customer (payer) and the utility (payee) have an adversarial 
relationship in the context of a payment system. The payer desires to pay a 
minimum amount and the payee desires to be paid a maximum amount. In order 
5 for the payment system to be effective it should be as free as possible from dispute 
over the bill amount. To minimize such disputes, the payer and payee should have 
confidence and trust in the accounting process of the payment system such that the 
payer and payee have a simple, effective way of reaching an agreement on the 
amount to be paid. The majority of utilities today use only one source of 

10 information for billing provided by the utility which does not give confidence to the 
customer that the billing procedure is correct. 

In the instance of usage-based charges the task of bill audit and 
verification by customers is frequently time consuming, and in the case of 
discrepancies between the received and expected bill — real or perceived — the 

15 results can be a potentially difficult and time consuming dispute resolution process 
with the utility. This is the case for disputes over the amount of telephone bills 
which is aggravated by the complexity of rates, fees and charges. Presently — 
particularly in the United States — telephone companies which generally operate in a 
commodity market attempt to favorably distinguish their services from competitors 

20 by introducing new and more complex charge plans which may include several 

variables such as distance (local, interstate, international) and time of day (day and 
night time charges) variables. Frequently businesses and households in order to 
minimize expenses use several different utility service providers causing even more 
time consuming and difficult bill auditing and verification procedures. 

25 From a utilities viewpoint the billing and revenue collection is the 

single, largest expense, the efficiency of which determines profit margins and the 
ability of utilities to compete in an increasingly competitive marketplace. 
Constraints on global economic efficiency demand that the overall revenue 
collection system for utilities, defined as combined costs incurred in the process of 

30 payment/ revenue collection by customers and utility service providers, be 
minimized. 

Accordingly, it is an object of the present invention to overcome these 
and other drawbacks and disadvantages associated with the revenue collection 
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system of usage-based utility industries and provide a set of intelligent features in 
the case when usage-based payment applications employ credit/debit cards. 

£1 JMMAR Y OF THE INVENTION 
5 Almost 95% of small and medium size businesses and over 50% of 

households in the industrial world own a personal computer. Personal computers 
are being used for a variety of data processing tasks, including accounting and 
payment. The present invention makes use of personal computer that can be 
interfaced with electronic devices such as telephones or modems that are used for 
10 utility services. The preferred embodiment of the present invention is illustrated 
with respect to telephone usage. 

In one aspect of the present invention, a method for payment of utility 
bills to a utility company includes monitoring utility usage of the consumer by a first 
monitoring subsystem associated with and under control of the consumer. 
15 Preferably, the monitoring system includes a line or connection monitoring device 
(LMD) for monitoring utility usage such as, for example, telephone usage. At least 
one customer generated fee calculation representing the amount due a utility 
company for utility usage of the consumer over a predetermined billing period is 
calculated by means of the first monitoring subsystem so that the customer has a 
20 trusted source for determining how much he or she should expect to pay the utility 
service provider. 

Utility usage of the consumer is also monitored by a second 
monitoring subsystem associated with and under control of the utility company. 
The first and second monitoring subsystems associated respectively with the 
25 customer and the utility service provider are distinct from one another. At least one 
utility generated fee calculation representing the amount due the utility company for 
utility usage of the consumer over the predetermined billing period is calculated by 
means of the second monitoring subsystem so that the utility service has its source 
for determining how much its customer should pay the utility service provider. 
30 The customer and utility generated fee calculations are then compared, 

and thereupon the payment of the amount due represented by one of the customer 
and utility generated fee calculations is authorized if any difference between the 
customer and utility generated fee calculations is within a predetermined threshold 
value. The fee calculations may be compared either by the customer or the utility 
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service provider upon prior agreement. For example, if the fee calculations are 
compared by the customer, the utility service provider will send or download to the 
customer's computer via the Internet the utility generated fee calculation for 
comparison with the customer generated fee calculation. If the fee calculations are 
5 compared by the utility service provider, the customer will send or download to the 
utility service provider's server via the Internet the customer generated fee 
calculation and pa)anent for comparison with the utility generated fee calculation. 

Preferably, the authorization for payment takes place as an electronic 
transfer of funds from a money withdrawal source of the customer to a money 

10 deposit source of the utility service provider. The customer and utility service 

provider may agree beforehand who authorizes the transfer. For example, if the 
customer compares the customer and utility generated fee calculations, the customer 
might authorize the transfer of money. Alternatively, if the utility service provider 
compares the customer and utility generated fee calculations, the utility service 

15 provider might authorize the transfer of money with the prior approval of the 

customer. In either case the absence of discrepancy enables a simple money transfer 
procedure. 

In another aspect of the present invention, a system for payment of 
utility bills to a utility company includes a first monitoring subsystem associated 

20 with and under the control of a consumer for calculating at least one customer 
generated fee calculation associated with the amount due a utility company for 
utility usage of the consumer over a predetermined billing period. A second 
monitoring subsystem communicates with the first monitoring subsystem, and the 
second monitoring subsystem is associated with and under the control of the utility 

25 company for calculating at least one utility generated fee calculation associated with 
the amount due the utility company for utility usage of the consumer over the 
predetermined billing period. One of the first and second monitoring subsystems 
compares the customer and utility generated fee calculations. Preferably upon 
comparison, the one of the first and second subsystems performing the comparison 

30 authorizes the payment of the amount due represented by one of the customer and 
utility generated fee calculations if any difference between the customer and utility 
generated fee calculations is within a predetermined threshold value. 

For telephone usage, a customer may have a calling plan which 
includes rates for different utility service providers as well as a precise method of 
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computation for charges given relevant time duration and parameters. At the end 
of any predetermined accounting or billing period, the personal computer of the 
customer may process and summarize the data, and output summary information 
either on the computer screen, on a hard copy such as paper from a printer, or on a 
5 magnetic or an optical media such as floppy diskette or CD-ROM. This summary 
information may contain, for example, totals of charges for different utility service 
providers and grand total of payment due for the accounting period. The process of 
computing summaries in. the user's personal computer in effect should replicate a 
similar process performed by the user's utility service provider such as the user's 
10 telephone company IT system. In the case of properly designed and functioning 
systems, the results of the expected amount due should be identical. 

There are several possible ways to verify for correct billing 
information. The task of verifying correctness of billing information is expected to 
be performed by all responsible customers. In its simplest form, the user upon 
15 receiving a bill from his or her utility companies detailing charges for a given 
accounting period (typically a month) enters the beginning and last days of the 
accounting period into his or her personal computer and outputs a summary of 
charges. This summary has been computed by the user's personal computer under 
the user's control based on the data that was measured by the user's own LMD 
20 device. Thus, the summary of charges or customer generated fee calculations 

should be completely trusted by the user provided that the integrity of the LMD 
device and the used computing algorithm is trustworthy. The LMD device and 
software can be guaranteed, for example by the manufacturer, since the device and 
process for calculating usage are well known and not complicated, and can be 
25 checked using techniques described below. 

Upon examination of the received bill the user may compare different 
charges or customer generated fee calculations including totals for local, long 
distance and international calls and the grand total, and if they are identical (or have 
a very small discrepancy, for example a few cents in the United States) the user 
30 issues and sends a check for the appropriate amount to the utility. This is the 

simplest case, and it provides limited economic benefits primarily to the customer. 
Alternatively, the utility company may choose to send the bill electronically directly 
to the user's personal computer (using, for example, the Internet). In this case the 
personal computer may perform the comparison between the utility generated fee 
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calculations in the received bill and the customer generated fee calculations in the 
computed summary. If this comparison results in a satisfactory match the personal 
computer may be instructed to issue an electronic payment, for example by sending 
appropriate information and instruction to the user's bank or a credit card company 
5 to deduct the total amount represented b)' the customer generated fee calculations 
indicated in the summary from the user's account and transfer it to the utility's 
account, the identity of which must be indicated in the bill. What constitutes a 
satisfactory match is predetermined by the user with the help of the flexible 
software allowing to change the criteria according to the user's desires. The process 

10 of bill payment thus may be completely automated so as to avoid entirely paper- 
based communication channels, thereby resulting in substantial savings to both 
customers and utilities. 

Alternatively, the present invention contemplates avoiding sending the 
utility bill. The user and the utility may agree on the method of payment and on a 

15 predetermined accounting period such as, for example, two to three weeks or less. 
The length of the accounting period is normally determined by the balance between 
cash flow requirements, cost of money (interest rates and float) and the cost of 
billing and remittance processing. In the traditional environment, because these 
latter costs become prohibitively large the billing for relatively small amounts can 

20 not be done too frequently. The present invention overcomes this difficulty. At the 
end of the accounting period the user's computer may automatically generate usage 
and activities summaries containing at least one customer generated fee calculation 
and send them electronically to the utility while simultaneously sending 
authorization for payment for the appropriate amount to the user's bank or a credit 

25 card company. The utility's IT system upon receiving user's summary automatically 
compares the customer generated fee calculation in it with the utility generated fee 
calculation or usage data accumulated by the utility company for the accounting 
period. If matched, the utility accepts the data and verifies that electronic transfer of 
funds represented by either the customer or utility generated fee calculation indeed 

30 took place and that utility's account has been appropriately credited. The important 
feature of both utility and customer initiated payment procedures of the present 
invention are that they create trust between a customer and his or her utility service 
provider by allowing them to compare data originated from two independent 
sources of information. Even more importantly, the present invention allows for 
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large reductions in expenses associated with bill generation, reconciliation (by the 
user) and remittance processing. These savings are estimated in the hundreds of 
millions or even billions of dollars since, for example, the cost bill generation, 
processing and remittance is estimated to be at $1.25-$1.50 per bill. Thus a single 
5 user's billing process generates $15 - $18 per year in only the processing costs. 

Further, the expense of donning notices, and conducting billing dispute resolution 
makes the cost per customer to be as high as perhaps $21-$25 per year. Since there 
are at least 60 million computerized households and small businesses just in United 
States alone, this cost can amount to $1.2 billion to $1.5 billion annually. The present 

10 invention may result in a loss of a small amount of money by the user due to lost 
float on real time payments. In compensation, utilities may provide incentives to 
users to subscribe to the above-described modes of payment by giving discounts for 
services based on sharing in cost savings. Thus, the present invention capitalizes and 
expands on a recent trend toward customer self-service utilizing increasing 

15 computational and connectivity abilities of customer devices. 

The confidentiality, integrity and authenticity of the data provided by 
either customer or utility or both may be achieved using modern tools of 
information protection as is more fully described below. 

The present invention allows users and utility service providers to 

20 negotiate customized rates for the services (using the Internet). The present 

invention permits, for example, the customer to create his own desired rate plan and 
send it to several utility service providers that may be interested in servicing this 
customer. If the plan is acceptable to a service provider, the service provider sends 
; acknowledgement to the customer. 

2 25 The LMD may be any device capable of recording usage data in 

addition to a device using a smart card attached to a connection line such as a 
telephone or a cable line. Smart cards are portable and can be carried by the user 
and can record payment-relevant information in any transaction. 

The system of the present invention also permits the measuring of 
30 both incoming and outgoing information from the user's personal computer such 
as, for example, the receiving and sending of digital products including movies, 
sound tracks, advertising messages etc. Other services may be used as well. For 
example, if there is a digital product distribution center with a menu of uniquely 
identifiable products with associated prices, the user may download various 
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products and automatically compute and facilitate payment in accordance with the 
present invention. Similarly, if a data distribution service is capable of sending 
advertising information (electronically or physically) to a custom definable list of 
receivers, and if the service has a price list with prices depending on the size of the 
5 message, size of the list and other similar parameters, then the user may select the 
service and compute and facilitate payment automatically using a menu of 
downloaded prices in accordance with the system of the present invention. 

The present invention also lends itself to automatic bills payment with 
a third party such as, for example, an Internet service provider. The user establishes 

10 a bank account accessible to a third party and at the end of the relevant accounting 
period the user sends all payment information (as measured by his LMD or other 
activity measurement devices and processed by his personal computer) to the third 
party authorizing the third party to make payment on his/her behalf. 

The present invention also allows customers to use several different 

15 service providers simultaneously and send payment for services in an efficient 
manner, and permits easy comparison between different service plans. For 
example, a customer can "play" different service scenarios and easily estimate 
charges for these scenarios using his application software. These and other 
advantages of the present invention can be appreciated from the detailed description 

20 provided below. 

The present invention ma)' be used with credit/ debit card 
billing/statement verification. A credit/debit payment card may be used as an 
intelligent portable device (IPD) capable of receiving information from an IPD 
reader/writer (also known as a terminal) installed at a point of sale in a merchant 

25 facility and the user's facility. The IPD may collect information of all users' 

purchasing activities and some preferences independently of computers employed 
by the credit card issuing company. Such use can be extended to home shopping 
using the Internet and e-commerce. If the user's personal computer at home is 
equipped with a terminal (an IPD reader/ writer) as a peripheral device, then this 

30 terminal may automatically record all purchasing activities executed from the user's 
personal computer at home or from any other publicly available computer. The 
credit/debit card number is automatically read by the terminal and sent to a 
merchant and by the merchant to a credit card computer, while the IPD 
simultaneously records all relevant information, thus creating an independent 



3DOCID; <WO 01503l2A1_l_> 



WO 01/50312 



9 



PCT/US00/34667 



record of purchasing activities. This approach has two additional benefits, namely 
the user does not have to key/type in his/her credit card number and thus saves 
effort and obtains an easy user-friendly and convenient way to shop. More 
importantly, this is a more secure method since entering credit/debit card 
5 information can be observed — especially in public places, and it is also error-prone. 
" Thus, the transfer of credit/debit card information using personal computers with 
attached smart card terminals is more secure than traditional systems. 

In the system of present invention the user may have a complete 
record of all his /her purchasing activities displayed at any desired moment in time 
10 and can compare this record with activities recorded by the credit/debit card 

operator obtainable, for example, through a credit/debit card company's web site. 
This has much improved security, since the user does not have to wait until the end 
of the accounting period to receive the bill /statement and compare it with the 
credit/debit card company's records, and in this way can detect fraudulent activities 
15 earlier and thereupon notify credit/debit card operator. The bill/ statement 

verification process is completely automated for the user and can alert the user of 
any fraudulent activities. 

The system of the present invention also allows for automatic 
downloading from specially designated web sites (servers) into the IPD various 
20 special discounts. The discounts create a highly effective automatic method that 
allows merchants to provide purchasing incentives complete with an automated 
payment mechanism. Special discounts can be downloaded only by authorized users 
(by user's access control through a password), thus allowing one-to-one marketing 
and discounting of merchandising. This allows individual discounts targeted to 
25 particular individuals, particular items (goods or services) or particular merchant 
facilities where a merchant might have an excessive inventory) or for a particular 
time period (if it is important for the merchant to sell goods before the end of a fiscal 
year or a quarter or any other significant event). 

The system of the present invention also allows users to have a single 
30 physical device that can function as multiple credit or debit cards. It is well known 
that many individuals carry multiple credit and debit cards so that they can have 
greater flexibility in using their credit lines. Specifically, the IPD device can be 
programmed to store several identification numbers, for example one for an 
American Express card, one for a VISA card and one for a Master Card. These can be 
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associated with single or multiple personal identification numbers (PINs). The 
advantage of this approach is that (besides a convenience of having a single card 
with multiple functionalities) it allows user's personal computer to preprogram the 
IPD for the card with optimal parameters. For example, a user having multiple credit 
5 lines and contemplating a purchase for a certain amount may have his personal 
computer search all available parameters of the user credit lines such as amount of 
available credit and interest rates charged and choose the optimal combination. The 
computer than can activate this optimal credit line as a preferred credit card number 
stored in user's IPD. 

10 Additionally the system of the present invention allows for a broad set 

of user control over the type of merchandise or service to be purchased, price, time 
period when purchases can be made and the like. These and other features of the 
present invention are fully described below. 

15 BRIEF SUMMARY OF THE DRAWINGS 

FIG. 1 schematically illustrates a system for facilitating the payment of 
utility bills embodying the present invention. 

FIG. 2 schematically illustrates a line monitoring device (LMD) used by 
the customer in accordance with the present invention. 
20 FIG. 3 schematically illustrates a usage recording device used by the 

customer in accordance with the present invention. 

FIG. 4 is an example of a rates plan file generated by the system of FIG. 
1 in accordance with the present invention. 

FIG. 5 is an example of a connection record generated under the 
25 control of a utility customer in accordance with the present invention. 

FIG. 6 is an example of an activities file generated under the control of 
a utility customer. 

FIG. 7 is an example of a billing file generated under the control of a 
utility customer. 

30 FIG. 8 is a flow diagram illustrating an example of a customer set up 

process for employing the system of FIG. 1. 

FIG. 9 is a flow diagram of a local accounting process under the control 
of a utility customer in accordance with the present invention. 
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FIG. 10 is a flow diagram illustrating as an example a billing file audit 
and reconciliation procedure in accordance with the present invention. 

FIG. 11 is a flow diagram illustrating as an example a discrepancy 
resolution process in accordance with the present invention. 
5 FIG. 12 is a flow diagram illustrating an example of a discount 

purchasing process in accordance with the present invention. 

FIG. 13 is a flow diagram illustrating an example of an intelligent 
portable device set-up process in accordance with the present invention. 

FIG. 14 is a flow diagram illustrating an example of an intelligent 
10 portable device usage transaction control process in accordance with the present 
invention. 

FIG. 15 is a flow diagram illustrating an example of an intelligent 
portable device credit line control process in accordance with the present invention. 

15 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Trust in the accounting process may be established for the payer and 
payee if they both have independent and trusted sources of accounting information. 
If the payer and the payee can verify the accuracy of their sources and control them, 
then they will have confidence in the accounting process. The process of examining 

20 the utility bill for correctness may be accomplished by a comparison of the 

information obtained from both sources. If the information obtained from the two 
independent sources match, then both payer and payee will be confident that the 
accounting information is correct and costly dispute resolution will be avoided. 

With reference to FIG. 1, a system for facilitating the payment of utility 

25 bills is generally designated by the reference number 10. The system includes a 
consumer subsystem 12 and a utility provider subsystem 13. The utility provider 
may be any type service which can be transmitted to the customer for a fee. Such 
utilities may be, for example, water, gas, electricity, telephone, cellular phone, cable 
television, Internet, research and other database utilization, on-line services such as 

30 stock tracking, music, video and other entertainment services. In other words, the 
utility may be any usage which can be measured so that a self bill or summary of the 
amount due for such usage can be created and paid automatically as long as the 
information transmitted is identified by the type of service. The customer may be, 
for example, an individual using a utility at his or her residence, or a corporate . 
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customer or business. For purpose of illustration only, the present invention .will be 
described with respect to telephone usage which may be employed over telephone 
lines or by wireless means for cellular phones. 

The consumer subsystem or local payment accounting system (LP AS) 
12 includes a line monitoring device (LMD) 14 coupled to a telephone line 16 for 
monitoring telephone usage of a telephone 18. The consumer subsystem 12 further 
includes a computer 20, such as a personal computer, typically equipped with a data 
communication device such as a modem or Ethernet card, wherein the computer is 
coupled to the LMD 14 and used by the consumer for calculating the amount of the 
user's telephone usage to be explained more fully below. The LMD 14 and the 
computer 20 are associated with and under the control of the consumer. The utility 
provider subsystem 13 has a server 22 which executes its central revenue accounting 
system. The customer subsystem 12 and the utility service provider subsystem 13 
communicate over a public communication network or Internet 17. The customer 
subsystem 12 and the utility service provider subsystem 13 (with authorization from * 
the customer) may have access to the customer's bank or credit card server 19 for 
electronic fund transfer of utility fees owed from the customer's money withdrawal 
source to the utility service provider's money deposit source, such as utility's bank 
server 21. 

As shown in FIG. 2, the LMD 14 preferably includes a microprocessor 
50 communicating with and controlling non- volatile memory 52, random access 
memory 54 and an input/ output interface 56 to be coupled to the personal 
computer 20 and the telephone line of the telephone 18 (see FIG. 1). The LMD 14 
may also communicate with a wireless device such as, for example, a cellular phone. 
This type of LMD is self-contained and includes, for example, a "smart card" for 
accumulating usage information. The LMD may then be inserted into a reader 
attached to the personal computer so that the computer may receive the usage 
information contained in the LMD, and thereupon generate fee calculations for the 
amount due for such usage. 

Devices such as the LMD 14 are well known in the art. (See, for 
example, U.S. Pat. No. 5,841,847.) These devices intercept electrical signals that travel 
along telephone lines without interrupting telephone conversations, or such devices 
transfer and exchange data. The LMD 14 is preferably installed between a user's 
telephone apparatus and outlet of the telephone line (jack). The LMD 14 also 
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communicates with the computer 20 through, for example, an RS 232 serial port, as 
is well known in the art. (See, for example, U.S. Pat. No. 5,841,847.) Thus, the user's 
personal computer 20 gains access to all data that can be measured by the LMD 14. 
Two types of LMD are possible. Preferably, the LMD 14 is an 

5 "intelligent" and tamper resistant LMD with a computer processor and a non- 
volatile memory and is capable of performing information security processes such 
as cryptographic computations. These devices, one example of which is "smart 
cards" or "chip" cards, are well known in the art. (See, for example, Smart Card 
Handbook by W. Rankl and W. Effing, John Wiley & Sons, 1999.) An intelligent 

10 LMD sends a raw summary of activities data to the user's personal computer 20 
while retaining a hash value and/or digital signature of the raw data for possible 
audit in the case of dispute or discrepancy over the amount the customer owes the 
utility service provider. A non-intelligent LMD merely sends to a computer a signal 
indicative of the recipient's telephone number and duration of the conversation 

15 (connection) as described in more detail below. 

As an example of an intelligent LMD, when a user enters a telephone 
number to initiate a telephone conversation, the LMD 14 may automatically send a 
signal to a personal computer indicative of: 

1) the identity information of the utility service provider, 

20 2) the telephone call recipient telephone number, 

3) the time of day when the connection has been established 
between the telephones of the user and the call recipient (time stamp of the 
beginning of the connection), 

4) the time of day when the connection has been terminated 

25 between the telephones of the user and the call recipient (time stamp of the end of 
the connection), and 

5) any other information which is relevant for computation of 
charges as defined by the utility service provider (for example the number of dial 
tones elapsed before the connection has been established). 

30 The precision of time measurements is determined by the required precision for 
computation of charges, but typically precision in seconds is sufficient. 

The LMD 14 may be any device capable of recording usage data in 
addition to a device using a smart card attached to a connection line such as a 
telephone or a cable line. For example, FIG. 3 illustrates an LMD implemented as a 
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usage recording device 15 having a smart card removably coupled to the usage 
device. Smart cards are portable and can be carried by the user and can record 
payment-relevant information in any transaction. When the user engages in a 
payment transaction such as when the user presents his or her smart credit or debit 
5 card for payment in a store, the card is inserted in a terminal capable of writing 
information on the card. This information can be a time-stamp and the unique 
identification code of a merchant as well as the amount of the transaction. When this 
information is recorded, simultaneously the terminal sends this information also to a 
server of the credit card company. This information then can be stored and made 

10 accessible to the user, for example, via a credit card company web site. This service 
is already available today. In doing so the credit card company implements 
appropriate confidentiality measures, making access to the confidential information 
password protected, using well known protocols, such as SSL. This arrangement 
saves the amount of operational memory required for the smart card. From a 

15 technical viewpoint, the only information that need be stored on the card is the 
unique identification of the transaction. Alternatively, if the user's personal 
computer is equipped with a smart card reader and smart card can store all relevant 
details of a transaction, the user then can review and process all his transactions 
using his/her personal computer. Such an arrangement allows the user to review all 

20 his or her transactions and authorize electronic payment at any moment — not only 
once a month as is typical today. In this arrangement it is possible to record both 
payments and credits such as, for example, for returned merchandise. Monitoring 
mobile phones is possible in a similar manner if mobile phones contain smart-card 
writing capabilities. The advantage over existing systems is the fact that transaction 

25 records are always maintained in two places with one of the places under control of 
the user, thus greatly improving trustworthiness and robustness of the entire 
system. 

Referring again to FIG. 1 using the LMD 14 as a telephone monitoring 
device, the personal computer 20 of the customer is used as a data repository for all 
30 relevant payment computation data received by the LMD 14. The personal 

computer 20 is provided with a software application program or trusted self-billing 
application software (LP AS), to be explained more fully below, that allows a user to 
enter all relevant details of the user's calling plan in an easy, flexible and user 
friendly manner. For example, the customer's computer 20 will use a utility service 
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provider's rates plan for generating a rates plan file (RPF), such as the rates plan file 
100 illustrated as an example in FIG. 4, for determining the amount to be paid by the 
customer for a customer initiated telephone conversation based on various factors 
such as the time of day and whether the call is local or long distance. 
5 As shown in FIG. 4, the rates plan file 100 includes a utility service 

provider identification 102, a rates plan identification 104, an optional customer 
identification/ account number 106, a hash value (or digital signature or Message 
Authentication Code) 108 of the rates plan file 100, local rates 110 for three, eight 
hour time periods of the day, national long distance rates 112a through 112n 

10 respectively covering first through nth area codes, international rates 114a through 
114m respectively covering first through mth country codes, service fees 116 and 
taxes 118 each covering three, eight hour time periods of the day. The hash 
value/ digital signature 108 is used to determine if the data of the rates plan file 100 
has been tampered with or otherwise corrupted and can serve as a legal basis for 

15 contract between the user and the utility. 

The trusted self -billing application software residing on the computer 
20 of the customer may be installed or executed by direct connection to a software 
service provider's server via the Internet, through a CD-ROM or floppy diskette that 
the user receives from the service provider, or in many other suitable ways. The 

20 LMD 14, shown in FIGS. 1 and 2, keeps track of connection records (CRs), such as 
the connection record 150 illustrated as an example in FIG. 5. As shown in FIG. 5, 
each connection record 150 includes a connection record identification and date 152, 
a utility service provider identification 154, a telephone number dialed 156, a time 
stamp of the beginning of the telephone connection 158, a time stamp of the end of 

25 the telephone connection 160, and a hash value or digital signature 162 of the 

connection record 150 to be used to determine if the data of the connection record 
150 has been tampered with or otherwise corrupted. 

The LMD 14, shown in FIGS. 1 and 2, accumulates a set of connection 
records that form an activities file (AF), such as the activities file 200 illustrated as an 

30 example in FIG. 6, which serves as an input to the accounting process. The activities 
file 200 of FIG. 6 includes, for example, an activities file identification 202, date 204, 
and a plurality of connection records established over the period of time covered by 
the activities file 200, such as the first through third cross records 206, 208, 210. The 
activities file 200 also includes a hash value 212 of the connection record 200 which 
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may be used to determine if the data of the activities file 200 has been tampered with 
or otherwise corrupted. The activities file 200 of FIG. 6 is stored in the non-volatile 
memory of the LMD 14 shown in FIG. 2, and is encrypted before being sent to the 
computer 20 of the customer subsystem 12 in order to protect against theft of the 
5 data received and transmitted by the LMD. If the LMD 14 were stolen, the LMD 
would not reveal any sensitive details of usage. The encryption process simply 
could be a symmetric key process such as described in Digital Encryption Standard 
described in Federal Information Processing Standard FIPS46-2. In this case, the 
computer 20 and the LMD 14 share a secret key that is generated within the LMD, 

10 sent to the computer during the system initialization process, and protected within 
the computer by an appropriate password. 

At the end of the accounting process the trusted self -billing application 
generates a billing file (BF), such as the billing file 250 illustrated as an example in 
FIG. 7, from the activities file and the rates plan file. The billing file 250 includes a 

15 utility service provider identification 252, a customer account identification 254, a 
payment bank account, or credit card number and expiration date 256, an 
accounting period 258, and a digital signature value together with the algorithm 
identification 260. 

The billing file 250 further includes customer generated fee calculations 
20 such as local call information including for each telephone call a date of call 262, 

telephone number 264, time of day call began 266, the duration of the call 268, the 
charge amount for the call 270, and the total charge 271 for the local calls. National 
long distance call information is also listed for each telephone call including a date of 
call 272, telephone number 274, time of day call began 276, the duration of the call 
25 278, the charge amount for the call 280, and the total charge 281 for the national long 
distance calls. Likewise, international call information is also listed for each 
telephone call including a date of call 282, telephone number 284, time of day call 
began 286, the duration of the call 288, the charge amount for the call 290, and the 
total charge 291 for the international calls. The billing file 250 also includes the total 
30 charge 292 of the local, national and international calls over the billing period, and 
may include utility service fees 294 and applicable taxes 296. Finally, the billing file 
250 includes a total charge 298 for the accounting period. 

Referring again to FIG. 1, the utility service provider subsystem 13 
includes the central revenue accounting system (CRAS) normally operated by a 
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utility company. The utility service provider subsystem 13 preferably includes a 
server, such as the server 22, connected to the Internet, or includes a main-frame 
fault tolerant computer with an appropriate connectivity capable of receiving data 
from the customer subsystem 12 and from a data collection system employed by 
5 switching systems. Such central revenue accounting systems are typically employed 
by telephone utilities. The utility service provider subsystem 13 keeps track of all 
customers 7 calls and maintains files of customers' charges or utility generated fee 
calculations as customer invoice files (CIFs). The process of creation and 
maintenance of the customer invoice file is well known in the art and has been used 
10 for many years. The customer invoice file serves as a basis for customer invoicing 
and contains data elements identical to the data elements in the billing file generated 
by the trusted self -billing application running on the customer's computer 20 as fully 
described below. (See FIG. 7.) At the end of any accounting period the billing file 
generated by the customer subsystem 12 and the customer invoice file generated by 
15 the utility service provider subsystem 13 should contain identical accounting data 
including all relevant charges represented by customer generated fee calculations in 
the billing file and utility generated fee calculations in the customer invoice file. This 
allows for a simple validation process by the utility service provider. The validation 
process compares customer and utility generated fee calculations as well as other 
20 charge accounting data in the billing file and the customer invoice file. If identical, 

the utility service provider accepts pa)>ment either via electronic fund transfer or via 
the credit card process. Such details of paj'ment transfer are also well known in the 
art. If, on the other hand, customer and utility generated fee calculations differ 
between the billing file and the customer invoice file, then the validation process 
25 determines the discrepancy between amounts. If this discrepancy does not exceed a 
predetermined threshold value, then the utility service provider subsystem 13 
accepts the validity of the billing file and initiates the payment process. The 
predetermined value is defined based on business and economic considerations. It 
can be set, for example, at a 1% level for all bills that do not exceed $100, at 0.1% for 
30 all bills between $100 and $1,000, etc. The predetermined value takes into account 
cost of investigation and dispute resolution as well as other important parameters, 
such as for example, the payment history of a customer. Of importance is that even 
small discrepancies between the billing file generated under the control of the 
customer and the customer invoice file generated under the control of the utility 
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service provider may be indicative of a systemic problem. During the course of 
normal operations all input data elements for computation of the billing file and the 
customer invoice file should have identical values. Any systematically observed 
difference between such elements may be indicative of malfunction in the LMD 14 or 
5 the trusted self -billing application of the customer, or a malfunction or bug in the 
hardware and software of utility service provider subsystem 13. The present 
invention, thus provides an effective detection mechanism for maintaining an error- 
free billing system. Maintaining an error-free billing system is substantially more 
difficult without having second independent source of information at the local site of 

10 the customer. 

Referring to FIG. 8, a set up process is illustrated for a customer using a 
trusted self-billing application software residing on the customer's personal 
computer 20 (see FIG. 1). The customer's personal computer 20 receives a rates plan 
file (see FIG. 4) from a utility service provider's web server, a CD-ROM, a diskette or 

15 by scanning or keying in the rates plan file from a paper document (step 300). The 
data integrity of the rates plan file is verified using a hash value/digital signature in 
the rates plan file and stored in the user's computer by means of an algorithm for 
computing a hash function (step 302). It is then determined if the contents of the 
rates plan file is consistent with its hash value (step 304). If not, a new rates plan file 

20 is received into the customer's personal computer 20. If the data is consistent, the 

LMD 14 (see FIGS. 1 and 2) generates a symmetric encryption key and transmits it to 
the personal computer 20 (step 306). The trusted self -billing application residing on 
the personal computer 20 receives the symmetric encryption key, prompts the user 
of the personal computer 20 for a password, executes password protection of the 

25 received key (step 308), and thereupon set up is complete (step 310). 

FIG. 9 illustrates the operation of the customer subsystem 12 of FIG. 1 
in monitoring and calculating the amount owed a utility service provider. The user 
operation begins when the user enters a telephone number (step 350). The LMD 14 
(see FIGS. 1 and 2) turns on, opens a new connection record, begins recording of 

30 telephone line signals, and time stamps the moment when connection between caller 
and recipient has been established (step 352). When the telephone connection is 
terminated by the caller and recipient, the LMD 14 stops recording the telephone line 
signals, time stamps the end of the connection, closes the connection record, and 
encrypts and stores the current activities file (step 354). The trusted self-billing 
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application residing on the customer's personal computer 20 determines whether it 
is the end of an accounting period (step 356). This is typically accomplished when 
the user indicates to the trusted self-billing application via the keyboard of the 
personal computer 20 that it is the end of the accounting period. This also can be 
5 accomplished upon receiving a signal from the central revenue accounting system of 
the utility service provider subsystem 13 without direct involvement of the user. If 
it is not the end of an accounting period, steps 350 through 354 are repeated for each 
subsequent telephone call initiated by the customer. If it is the end of an accounting 
period, the LMD 14 closes the activities file, and the trusted self -billing application 
10 receives the activities file from the LMD 14 and decrypts it (step 358). The trusted 
self -billing application computes charges for the accounting period using the rates 
plan and the activities files and generates the billing file (step 360). The trusted self- 
billing application digitally signs and encrypts summary billing file, and displays and 
prints plain text data on request from the user (step 362). The billing file is digitally 
15 signed and encrypted to protect confidentiality and integrity of the data in the billing 
file as well as to authenticate the customer to the central revenue accounting system 
of the utility service provider subsystem 13 as the legitimate owner of the billing file. 
The process may use any of the existing and well known in the art protocols such as 
SSL or SET. (See for example, S. Thomas, SSL and TIs Essentials: Securing the Web, 
20 John Wiley & Sons, 2000.) 

Other methods of signing and encryption are equally possible. For 
example, in the simplest possible way, signing and encryption may be accomplished 
merely by including a public key of the central revenue accounting system of the 
utility service provider subsystem 13 into the rates plan file. This key then can be 
25 used for signature and encryption, provided that the public key encryption scheme 
being used is reversible. The trusted self -billing application sends the signed and 
encrypted billing file to the central revenue accounting system of the utility service 
provider subsystem 13 for reconciliation and appropriate payment instructions 
either directly to the customer's bank or to a credit card company, and thereupon 
30 the process ends for the accounting period (step 366). In the above process, the 
control over the payment process resides with the customer which minimizes 
customer disputes over the utility bill. 

FIG. 10 illustrates an example of a billing file audit and reconciliation by 
a central revenue accounting process of the utility service provider subsystem. A 
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billing file is received at the utility service provider subsystem 13 from the customer 
subsystem 12, as shown in FIG. 1 (step 400). The central revenue accounting system 
of the utility service provider subsystem 13 decrypts the billing file and verifies its 
digital signature (step 402). It is then determined by the subsystem 13 whether the 
5 verification fails (step 404). If yes, the utility service provider investigates (step 406). 
If the verification passes, the central revenue accounting system retrieves accounting 
charge data elements including utility generated fee calculations from the customer 
invoice file generated by the utility service provider subsystem 13 and compares 
them with the charge data elements including customer generated fee calculations of 

: . 10 the billing file generated by the customer subsystem 12 (step 408). The utility service 
provider subsystem 13 then determines if the data elements of the customer invoice 
file and the billing file match (step 410). If there is a match, the utility service 
provider subsystem 13 initiates a payment acceptance process of an amount 
represented by one of the customer and utility generated fee calculations (step 412). - 
15 If the data elements do not match, the utility service provider subsystem 13 

computes the discrepancy and retrieves a discrepancy threshold amount determined 
by business and economic considerations of the utility service provider (step 414). 
The utility service provider subsystem 13 then determines whether the discrepancy 
exceeds the threshold (step 416). If the threshold is not exceeded, the payment 
20 acceptance process is initiated (step 412). If the threshold is exceeded, a dispute 
resolution process is initiated (step 418). 

FIG. 11 illustrates an example of a discrepancy resolution process by 
the central revenue accounting system of the utility service provider subsystem. 
The central revenue accounting system of the utility service provider subsystem 13 

? 25 (see FIG. 1) retrieves accounting charges from the billing file generated by the 

customer and the customer invoice file generated by the utility service provider and 
compares their data elements (step 450). The central revenue accounting system 
then determines whether the billing file and the customer invoice file contain 
different beginning or ending times (step 452). 
30 If the billing file and the customer invoice file contain different 

beginning or ending times (step 452), the central revenue accounting system 
executes a diagnostic and determines the source or sources and cause of the 
discrepancy (step 454). If it is determined that the discrepancy is deliberate by the 
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customer (step 456), a criminal investigation is initiated (step 458). If the discrepancy- 
is not deliberate, a recovery process is initiated (step 460). 

A discrepancy of the beginning and ending times in the billing file and 
the customer invoice file may be indicative of malfunction in the LMD 14 of the 
5 customer or the central revenue accounting system hardware and /or software. 
Systemic differences would allow a diagnostic software in the central revenue 
accounting system to determine possible cause(s) of discrepancy and verify it by 
requesting connection records from the LMD 14 and similar records from the central 
revenue accounting system. 

10 If the billing file and the customer invoice file contain the same 

beginning and ending times (step 452), then the central revenue accounting system 
determines if there are any missing records of some connections in the billing file or 
in the customer invoice file (step 462). If there are missing records, the diagnostic 
(step 454) and subsequent steps are executed to determine the source and cause of 

15 the discrepancy, as well as to determine whether the discrepancy is deliberate. 

If the BF does not include some connections recorded in the customer 
invoice file, it may be indicative of a hardware malfunction, or a deliberate 
disruption of the LMD 14 by the user. In the latter case, the user may have 
attempted to disconnect the LMD in order to avoid payment. In this case the utility 

20 service provider may request examination of the LMD 14. By design, the LMD 14 
contains non- volatile memory (see FIG. 2) and stores digitally signed records of all 
calling activities. Absence of records that are clearly present in the customer invoice 
file may provide evidence of deliberate fraudulent attempts so as to warrant 
criminal investigation and requiring proof of calling activities from receivers of calls 

25 that are missing from the billing file. Further, if the customer invoice file does not 
include certain connections recorded in the billing file, this may be a clear indication 
of malfunction within the central revenue accounting system. Such absent records 
will enable the utility service provider to be aware of its problem in order to 
thereupon fix the problem within the central revenue and accounting system. 

30 If there are no missing records (step 462), it is then determined 

whether the billing file is based on a rates plan file that is different from that used by 
the utility service provider (step 464). If the billing file is based on a different rates 
plan file, then the diagnostic (step 454) and subsequent steps are executed to 
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determine the source and cause of the discrepancy, as well as to determine whether 
the discrepancy is deliberate. 

The rates plan file of the utility service provider contains a hash 
value/digital signature to protect its data integrity. A corruption in data integrity is 
5 indicative of a hardware or software malfunction in the customer subsystem 12 or 
central revenue accounting system of the utility service provider subsystem 13 or 
both. An appropriate diagnostic procedure will be able to determine the location of 
the problem and fix it. 

If the billing file is based on the same rates plan file (step 464), it is then 

10 determined whether the billing file and the customer invoice file contain amounts 
owed generated from different computing algorithms (step 466). If the billing file 
and the customer invoice file are based on different computing algorithms, then the 
diagnostic (step 454) and subsequent steps are executed to determine the source and 
cause of the discrepancy, as well as to determine whether the discrepancy is 

15 deliberate. 

The trusted self-billing application of the customer running on his or 
her personal computer 20 can be certified to perform correctly and provided with a 
hash value of the trusted self-billing application. In case of discrepancy between 
computing algorithms, the customer's personal computer 20 may verify the 

20 correctness of the trusted self-billing software application computational algorithm 
before every execution. A similar procedure may be employed at the central 
revenue accounting system of the utility service provider subsystem 13. The 
discrepancy verification process will determine and verify possible causes of 
discrepancy. Again, a deliberate attempt by the user to substitute correct trusted 

25 self -billing software with something else will be detectable by the utility service 

provider. The utility company then can use such discrepancy as proof of deliberate 
fraud and fine or prosecuteperpetrators. This procedure will provide a strong 
deterrence effect to tampering with the trusted self-billing application. 

However, if the trusted self -billing application is proven to be correct, 

30 then any discrepancy between the billing file and the customer invoice file 

computing algorithms is indicative of a malfunction within the central revenue 
accounting system of the utility service provider subsystem 13. Appropriate 
diagnostic procedures well known in the art enable the utility service provider to 
determine the location of the problem and thereupon fix it. 
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If the billing file and the customer invoice file are not based on 
different computing algorithms (step 466) the process is stopped (step 468) and 
further investigation must be decided for the specifics of the case. 

Although the system for facilitating payment of utility bills has been 
5 described by way of example with respect to telephone usage monitored by the user 
from a personal computer, the system may also be used in other applications taking 
place at the user's personal computer or at remote locations relative to the user's 
personal computer as will be explained with reference to FIGS. 12-14. In such 
applications, the line monitoring device (LMD) 14 shown in FIG. 2 may be a portable 

10 device including a microprocessor 50, non volatile memory 52, random access 
memory 54 and an input/output interface 56. Portable LMDs are capable of 
retaining memory content without a continuous power supply (e.g. battery-less 
devices) and are particularly beneficial for applications with credit/ debit payment 
cards- In this case the LMD may be called an intelligent portable device (IPD) since 

15 the main function of the device shifts from monitoring to certain intelligent functions 
as described in full detail below. Examples of IPDs are well known in the art and 
include, for example, " smart cards" and PCMCIA cards which are more complex 
devices than smart cards. Smart cards typically have up to 64 or 128 Kbytes of 
memory. PCMCIA cards typically have more memory and more powerful 

20 processors, but are bulkier and more difficult to interface with the outside devices. 
For the purpose of the present invention to be explained below, the IPD preferably 
has 1) a memory capable of holding information without a continuous power 
supply, 2) a microprocessor capable of executing various computations including 
comparison tests, and 3) an input/ output system in communication with external 

25 devices for downloading and uploading information from such devices. Other 

devices having battery-supported memory are not precluded from use with systems 
embodying the present invention but would be less convenient than devices without 
batteries. 

As mentioned previously with respect to FIG. 3, the present invention 
30 may be used with credit/debit card billing/statement verification. A credit/debit 
payment card used as an IPD capable of receiving information from an IPD 
reader/writer 15 (also known as a terminal) installed at a point of sale in a merchant 
facility and the user's facility. The IPD collects information of all users' purchasing 
activities and some preferences independently of computers employed by the credit 
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card issuing company. Such use can be extended to home shopping using the 
Internet and e-commerce. If the user's personal computer at home is equipped with 
a terminal (an IPD reader /writer) as a peripheral device, then this terminal may 
automatically record all purchasing activities executed from the user's personal 
5 computer at home or from any other publicly available computer. The credit/debit 
card number is automatically read by the terminal and sent to a merchant and by 
the merchant to a credit card computer, while the IPD simultaneously records all 
relevant information, thus creating an independent record of purchasing activities. 
This approach has two additional benefits, namely the user does not have to 

10 key/ type in his/her credit card number and thus saves effort and obtains an easy 
user-friendly and convenient way to shop. More importantly, this is a more secure 
method since entering credit/debit card information can be observed — especially in 
public places, and it is also error-prone. Thus, the transfer of credit/debit card 
information using personal computers with attached smart card terminals is more 

15 secure than traditional systems. The system of present invention requires that this 
terminal have the ability to write into the memory of the IPD. This is easily 
accomplished and devices with such capability are commercially obtainable and well 
known in the art. 

In the system of present invention the user may have a complete 

20 record of all his/her purchasing activities displayed at any desired moment in time 
and can compare this record with activities recorded by the credit/debit card 
operator obtainable, for example, through a credit/debit card company's web site. 
This has much improved security, since the user does not have to wait until the end 
of the accounting period to receive the bill /statement and compare it with the 

25 credit/ debit card company's records, and in this way can detect fraudulent activities 
earlier and thereupon notify credit/debit card operator. The bill/statement 
verification process is completely automated for the user and can alert the user of 
any fraudulent activities. 

When smart cards (IPDs) are employed as credit cards, their ability to 

30 execute fairly complex computations is used primarily for identification/ 

authentication purpose to protect against fraudulent misuse of the card (see for 
example U.Hansmann, M Nickious, T.Schak, F. Seliger, Smart Card, Application 
Development Using Java, Springer- Verlag, 2000). However, there are many other 
useful applications that can take advantage of the IPD computational abilities. For 
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example, it is cumbersome and difficult to implement multiple special discounts and 
negotiated rates programs. When an entity negotiates a special discount for its 
representatives or employees with another entity (a merchant) for purchasing of 
certain items (which is frequently the case with fairly expensive items such as office 
5 computers, printers, fax machines, transportation tickets, lodging rates and the like) 
a variety of paper-based notices and certificates are distributed to different parties 
involved, such as employees and clerks working for the merchant. Purchasers 
involved have to remember to carry these paper-based documents to merchant's 
facilities and the process of verification of their validity is long, cumbersome and 

10 prone to errors. Users may also want to control various aspects of payment 

transactions independently of the smart credit/debit card (or other IPD) issuing 
company. Also, a merchant or a manufacturing company may want to eliminate 
excessive inventories by offering their preferred customers discounted prices. In 
this case, purchasers would be provided with an authenticated access to special web 

15 sites (servers) (for example through e-mail or direct mail) where they can review 
offered goods and services and download discounted prices into their IPDs (e.g. 
smart cards). 

This is not possible with existing systems, and yet has many benefits as 
described below. The present invention aims to overcome these and other 

20 difficulties by using computational capabilities inherent in the IPDs. This comes 

essentially at no cost since these capabilities are already built into the IPDs (such as 
smart credit/debit cards) for reason of security. 

When a company negotiates a special discount with a merchant for its 
employees and agents, it would normally distribute information concerning 

25 discounts through paper-based documents. These documents must be presented at 
the time of purchase for verification in a face-to-face manner at the point of sale or, 
alternatively, certain identification information must be communicated (through a 
telephone or a computer network) in the case of remote purchasing activities. In 
either case, the information has to be checked by a merchant's clerk either manually 

30 or automatically by a computer upon entry into computer system. The process is 
time consuming and prone to errors and purchasers frequently can not obtain 
discounts either because they forget to ask for discounts or because they choose not 
to ask because of the complexity of the process. As a result, millions of dollars are 
unclaimed depriving purchasers of substantial savings and thereby forcing 
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merchants into other less effective methods of reducing inventory. Effective 
management of the process of individual marketing and merchandising with 
(custom) discounts is a big challenge. It is an especially acute problem now when 
special discounts and one to one marketing are becoming increasingly popular tools 
5 of commerce. The system embodying the present invention overcomes these and 
"other difficulties by automating the process of claiming a discount and payment by 
using intelligence of the IPD. 

Any discount program involves a merchant party and a purchasing 
party. The purchasing party includes its employees or other agents that are referred 
10 below as users or consumers. Each user has a personal computer connected to a 

computer network (such as the Internet) and is capable of downloading information 
from other computers and servers connected to the same network. The information 
typically is accessed from Internet web sites associated with the merchants. In 
addition each user has an IPD such as smart credit/debit card or the like. Each 
15 merchant party has computerized terminals such as an IPD reader/ writer. These 
terminals are connected to distributed point of sales computers or other centralized 
computers /servers containing information concerning all available merchandise. 
This information is described in more detail below. 

The information parameters that are required for implementation of 
20 various applications with IPD are as follows: 

First, items that are subject to special rates or purchasing prices must 
be identified. We shall use the notation « Itemld» for the item identifiers. For 
example, standard universal codes or a part of such codes can be used as « 
Itemld» to identify items or classes of items. The « Itemld» may identify 
25 various physical merchandise items such as household goods, items of clothing, 
pieces of office equipment, as well as services such as automobile repairs, 
maintenance, travel services, tickets and the like. 

Second, the merchant providing discounts or special rates must be 
uniquely identified. We shall use notation «Merchant&FacilityId» for merchant 
30 identity including identities of all merchants' facilities where discounts are applicable. 
For example, folio numbers may be used as «Merchant&FacilityId» to identify 
hotel operators. 

Third, the price for the item must be accounted for. In one example, a 
percentage or amount of a negotiated or offered discount needs to be identified. To 
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accommodate various applications and controls we shall use notation 
«Price/Discount» meaning ether absolute value of the price or absolute value or 
relative discount expressed as percentage of the price before discount depending on 
the application. 

5 Fourth, for any application requiring intelligent control with the IPD a 

validity period must be established. This typically means date and time of the 
beginning and the end of a validity period. We shall use notation «Validity» to 
identify the validity period. 

Additional information may be provided. In other words, the list of 

10 the identified information parameters is in no way exhaustive and is meant to 

represent a set sufficient for illustrative examples. For example, typically the IPD has ' 
a single unique identification number (also known in the case of credit or debit card 
as a card number). This does not have to be the case with the IPD employing 
computational capabilities inherent in intelligent devices such as smart cards. The 

15 IPD may store multiple identities that can be associated with different credit or debit 
card service providers. These identities may be associated with different PIN 
numbers or a single PIN number depending on the application. The user can choose 
the card identity « IPD ID» either prior to engaging in the purchasing activity or 
during the purchasing activity. The benefit of these arrangements are twofold. 

20 First, if a user has multiple credit lines with different associated parameters (e.g. 
credit limit and interest rate), the user may activate the credit line with optimal 
parameters for every purchasing activity by notifying merchant's clerk (in the case 
of face-to-face purchasing) or through a user's personal computer in the case of 
purchases over the Internet. Second, a single IPD provides great convenience for 

25 the user and additional security for the IPD's issuing company because there is a 
lesser chance of losing a single card than losing multiple cards. 

The system of the present invention including the IPD may be 
employed for distributing special discounts. Negotiations for special discounts are 
typically done by a purchasing agent or other party either through direct 

30 negotiations or through other commercial mechanisms such as computerized 
auctions. 

Upon negotiating a special discount, the purchasing party places all 
relevant information for all negotiated items such as « Itemld», 
<<Merchant&FacilityId>>, «Price/Discount» and «Validity»at an appropriate 
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web site or other computerized data base easily accessible by computers that belong 
to users. Only authorized personnel using appropriate methods of access and 
channel security controls (e.g. passwords, biometrics, SSL or similar secure 
communication protocols) can access such web sites. All required information 
5 including, but not limited to «ltemld» / «Merchant&FacilityId», 

«Price/Discount» and «Validity»is formatted for downloading to computers 
that belong to users. These users for example may be required to regularly access a 
special web site or other computerized data base containing «ltemld», 
«Merchant&FacilityId», «Price/Discount» and «Validity» information and 

10 designated for discount programs by the purchasing party to download this 

information through their computers into their EPDs. The process of downloading 
discounts into an IPD is protected against inadvertent or deliberate data alteration 
by employing hash/digital signature mechanisms as described above for the utility 
(telephone) rates downloading. 

15 The merchant party upon negotiating special discounts with the 

purchasing party also places all relevant information such as «ltemld», 
<<Merchant&FacilityId>>, «Price/Discount» and «Validity» at all point-of-sale 
computers or a central computer accessible by the point-of-sale computers with 
attached IPD terminals. All other computers that host web sites of the merchant 

20 party and designed to facilitate purchasing over the Internet using methods of e- 
commerce are also provided with this information. All relevant merchants' 
computers containing information concerning all negotiated discounts will be 
referred to as "merchant's computer ". 

All users and agents of the merchant that can be engaged in 

25 purchasing activity are provided with the relevant computerized information fully 
describing details of the negotiated arrangement. 

The purchasing transaction proceeds as follows. A user presents 
his/her IPD (possibly together with an item that he/she intends to purchase) at a 
merchant facility (when purchasing is done face-to-face). Alternatively the user 

30 inserts his/her IPD into an EPD reader/ writer attached to his/her personal computer 
(or the like) when purchasing is done over the Internet. The EPD contains all 
relevant discount information that was previously downloaded from the purchaser 
secure web site while all the merchant's relevant computers contain the same 
discount information as described above. 
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In the case of face-to-face purchasing, a clerk employed by the 
merchant enters item-related information into the point-of-sale computer while the 
user enters his/her password or other identification information into the IPD's 
reader/ writer. Upon successful completion of the identification process which 
5 authenticates the user IPD to the merchant's point-of-sale computer and vice versa, 
the «ltemld» is transferred to the IPD's reader/writer together with the 
«Merchant&FacilityId» and the merchant's nominal price for the item. The IPD's 
reader/writer enters this information into the IPD. Upon receiving «ltemld» / 
«Merchant&FacilityId» and the nominal price for the item the IPD compares this 

10 information with the information on «ltemld» and «Merchant&FacilityId» 
stored in its memory and computes an appropriate discount using 
«Price/Discount» information if the item is entitled for a negotiated special 
discount. (If the item is not a subject to a negotiated discount, the IPD upon 
approval of payment of the nominal price by the user, stores the information 

15 including the paid nominal price for future verification by the user and the process 
terminates.) Then the IPD through the IPD's reader/writer terminal notifies 
merchant's point of sale computer or (through a network) a central merchant's 
computer of the negotiated price and requests a discount. At this point information 
«ltemld», «Merchant&FacilityId», «Price/Discount» and «Validity»is 

20 transferred for verification to the merchant's computer. If «ltemld», 

«Merchant&FacilityId», «Price/Discount» and «Validity» information 
transferred from the IPD matches similar information stored in the merchant's 
computer, the merchant's computer authorizes the transaction and the process 
terminates after all required information is stored in the IPD memory. If two sets of 

25 information parameters do not match, the process terminates and a manual 
investigation commences. 

FIG. 12 shows by way of example a flow chart of a purchasing process 
using negotiated discounts in accordance with the present invention. Prior to 
commencement of a discount purchasing process, a user executes a secure 

30 communication session with a purchaser's or merchant's web site by, for example, 
entering an identification and password (step 500). When such secure 
communication session has been established, the user downloads into his/her IPD's 
memory « Itemld», «Merchant&FacilityId», «Price/Discount» and 
«Validity» parameters while the same information is loaded into the merchant's 
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computer (step 502). In addition to these parameters, upon completion of 
negotiations the merchant computer also stores a list of identity numbers of all IPDs 
that are entitled for the discount program. 

Upon arriving at merchant's facility, the user inserts his/her IPD into 
5 an IPD reader/writer attached to merchant's point-of-sale computer and presents an 
item to be purchased to a clerk (step 504). Then the user at step 506 enters his/her 
identification information such as password or PIN into the IPD reader/ writer, and 
the IPD and the IPD reader/writer authenticate each other using one of the standard 
cryptographic protocols well known in the art (see, e.g., U.Hansmann, M Nicklous, 

10 T.Schak, F. Seliger, Smart Card, Application Development Using Java, Springer- 
Verlag, 2000). At step 508, the merchant's clerk enters item-related information 
including Nominal Price and « Itemld» into the IPD reader/writer (the 
«Merchant<SdFacilityId» parameter is fixed and always stored in the IPD 
reader /writer). The determination is made as to the success of authentication 

15 process (step 510). If authentication is not successful, the process terminates and 
manual investigation may commence (step 528). If the authentication is successful, 
the process continues where « Itemld», «Merchant&FacilityId», 
«Price/Discount» and «Validity» parameters are retrieved from the IPD 
memory (step 512). The retrieved « Itemld», «Merchant&FacilityId» and « 

20 Itemld» entered by the clerk and <<Merchant&FacilityId>> stored in the IPD 
reader/ writer memory are compared (step 514), and the determination of their 
match is made (step 516). If they do not match, the IPD stores « Itemld», 
«Merchant&FacilityId» and the nominal price in its memory upon purchase 
approval by the user and the process terminates (step 520). If they match, the IPD 

25 computes correct «PurchasePrice» using «Price/Discount» information (step 
518) and the process continues where «ltemld», «Merchant&FacilityId», 
«PurchasePrice», Nominal Price and «Validity» parameters together with the 
IPD identification information are transferred from the IPD into the merchant's 
computer (step 522). The merchant's computer using the IPD identification 

30 information as a search parameter compares « Itemld», 

«Merchant&FacilityId», «PurchasePrice», nominal price and «Vaiidity» 
parameters obtained from the IPD with « Itemld», «Merchant&FacilityId», 
«Price/ Disco unt», Nominal Price and «Validity» information that has been 
stored in its memory (step 524), and the determination of their match is made (step 
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526). If they match, the merchant computer authorizes the transaction (step 530) 
and the process moves to the step 520. If, on the other hand, they do not match the 
transaction terminates and a manual investigation begins (step 528). The overall 
process may continue if a new item is presented for a purchase (step 532). In this 
5 case the process begins again (step 508); otherwise the overall process terminates 
(step 534). 

In the case of purchasing through the Internet using e-commerce tools, 
the processes of the information submission from the IPD and the verification by the 
merchant's computer proceed in a similar fashion mostly without human 

10 involvement, except for the necessary "point and click" operations required for the 
identification of desired items by the user. 

The case described here is particularly suitable for users that are 
employed by. medium to large size companies capable of negotiating special 
discounts with travel service providers, office equipment suppliers and the like. 

15 However, the above-described method in accordance with the present invention 
works equally well with transactions other than above-described advertised or 
negotiated discount promotions. For example, consider the case when a merchant 
uses a direct mail or direct e-mail advertising program for initiating a special 
discount or promotion program. In this case, a user receives through regular mail 

20 or e-mail a notification of special discounts for different items or services together 
with his/her specially designed personal identification data that allow the user to 
access a secure merchant's web site and download all required information into 
his/her IPD. 

One feature of the present invention allows reduction of 
25 communications between a merchant's point-of-sale computer and its central 

computer. Specifically, upon execution of a first transaction after a secure session 
between the point-of-sale computer and a central computer (server), the central 
computer can download all information required for verification of the discount into 
the point-of-sale computer. After this all verification computations can be done 
30 locally. This can be useful when there are restrictions on the bandwidth or the time 
allowed for a transaction. 

In the case of double accounting, when a merchant's clerk or a 
merchant's computer inadvertently or deliberately attempts to charge the user 
multiple times for the same item, the IPD notifies /alerts the user of identical 
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charges/ identical items and may require manual intervention and approval before 
writing into the IPD memory details of the completed transaction. This and other 
similar intelligent functions can be programmed into the IPD by the user or the IPD 
issuer. This is particularly beneficial in reducing typically high costs associated with 
5 resolution of disputes concerning credit/debit card purchases. 

Beside facilitation of discount programs, the system of the present 
invention may be especially beneficial to control expenses by using pre-specified 
criteria that can be formulated by users and downloaded into their IPDs. The criteria 
can be formulated in terms of information (transaction) parameters downloaded 

10 into the IPD. For example, users may impose any combination of restrictions on 
transaction parameters such as «ltemld», «Merchant&FacilityId», 
«Price/Discount» and «Validity» by downloading restriction criteria into the 
IPD. This means that authorized users (accountable for all the charges incurred with 
their IPD) may specify that certain items can not be paid for using their IPDs, or they. 

15 may restrict prices that can be paid for certain items. Similarly, users may restrict 
facilities where the charges can be made or the validity period for allowed charges 
or the validity period for the entire IPD. Any combination of restrictions may be 
imposed. For example, authorized users may allow only charges below a certain 
limit at only given facilities and only during a given period. This is beneficial for 

20 controlling certain travel expenses as companies frequently try to do. Another 

example is the use of credit cards given to teenagers by their parents or guardians. 
The authorized user may not only easily limit the total amount (which can be done 
today only by requesting a special credit card from a credit card company or a 
bank), but may also prohibit the use of card for purchasing alcohol, tobacco 

25 products and the like. Spouses of compulsive buyers may also find this feature 

highly desirable. There is no effective mechanism today to impose such restrictions. 
The system of the present invention allows user's definition and implementation of 
various restrictions on the use of credit or debit cards and other similar payment 
mechanisms without involvement of credit/debit card issuers. Implementation of 

30 such restrictions within an existing centralized system is nearly impossible and even 
with the use of smart cards would be cost prohibitive. This is particularly beneficial 
since the method of the present invention does not require credit/debit card issues 
to relinquish all traditional controls, checks and balances employed for the purpose 
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of limiting financial losses. These and other intelligent processing features of the IPD 
are entirely within the scope and the spirit of the present invention. 

The process of usage control according to the system of present 
invention is depicted in FIG. 13 (IPD control set up process) and FIG. 14 (IPD control 
5 usage process). 

Referring now to FIG. 13, during the set up process an authorized user 
specifies his/her identification information that is personal to the authorized user. 
This can be biometric information such as a fingerprint or an eye's retina image or 
simply a PIN number. In the system of the present invention, the authorized user 

10 has a higher level of control than other users of the account. This means that there 
are several IPDs that may have the same account identification number but different 
user's identification information. This also means in practice that the authorized 
user's identification information allows him/her to change controllable transaction 
parameters as described below. All other users of the same account such as 

15 members of the household or subordinate employees typically have identification 
information that does not allow them to change controllable transaction parameters 
or lift restrictions imposed by the authorized user. Mechanisms to do so through so 
called master accounts and various levels of administrative privileges are well 
known in the art and are exercised daily by computer systems. 

20 As shown in FIG. 13, the IPD digitally signs and stores an authorized 

user's identification information (step 600). The authorized user inserts his/her IPD 
into an IPD reader /writer interfaced with a personal computer (step 602), and the 
user is prompted by the personal computer to enter his/her identification 
information such as, for example, a password and personal identification number, 

25 fingerprint, retina image and the like (step 604). This information is transferred to 
the IPD, which verifies its correctness (step 606). The determination is made 
whether the entered information is correct (step 608). If the information is correct, 
the process continues at step 612 where the authorized user enters restrictions on 
transaction parameters (in the example shown, the user wishes to restrict purchasing 

30 to a class of items with identification numbers beginning with ABC 123, that can be 
purchased only from the merchant identified by the number 765423, and only if 
their price does not exceed $75.00 and only from November 9 until December 9 of 
the year 2000). Then the IPD stores the entered parametric restriction and the 
process successfully terminates (step 614). If the authentication process at step 606 
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fails, then the process terminates without any changes to the parameters stored in 
the IPD (step 610). 

Referring now to FIG. 14, a flow chart of the usage control process in 
accordance with the present invention is described by way of example. The user 
5 interfaces /inserts IPD into an IPD reader/ writer at a merchant's facility and enters 
his/her identification information (step 700). The EPD verifies the user's " 
identification information and mutual authentication between the IPD reader/writer 
and the IPD is performed (step 702). The determination of success of these 
operations is made (step 704). If they are successful, then the merchant's clerk enters 

10 into the point-of-sale computer all required item-related information including 

«ltemld» and nominal price (step 706). If the identification/ authentication at the 
step 702 fails, then the process terminates with a failed transaction and manual 
investigation may begin (step 708); otherwise the process continues where item- 
related information including «ltemld» and nominal price together with 

15 «Merchant&FacilityId» is transferred into the IPD (step 710). The IPD checks 
restrictions /constraints on transaction parameters «ltemld», 
«Merchant&FacilityId», «Price/Discount» and «Validity» (step 712). The 
determination is made whether all restrictions are satisfied (step 714). If they have 
been satisfied, all transaction parameters are stored in the IPD memory for 

20 subsequent verification by the user and the transaction successfully terminates (step 
716). If the restrictions stored in the IPD are not satisfied the process terminates with 
a failed transaction (step 708). In this case, there are no changes in the IPD memory. 

Referring now to FIG. 15, a flow chart of a credit line control process in 
accordance with the present invention is described by way of example. The user 

25 typically has multiple credit lines with different available interest rates, credit limits 
and fees. This means that a user's personal computer has access a Credit File (CF) 
which may, for example, appear as shown in Table 1 set forth below: 



Credit Line ID or 
« Card ID » 


Credit Limit 


Available 
Credit 


Daily Interest 
Rate 


Late Fees 




1. VISA 1234 5567 0045 
8734 


$ 5,000.00 


$3,566.77 


0.05315% 


$25 




2. VISA 9334 5867 1255 
3478 


$ 1,000.00 


$275.00 


0.05232% 


$30 
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3. MC 9834 5588 0145 
893778 


$ 2,000.00 


$1,563.50 


0.04987% 


$15 




4. OPTIMA 9375 1389 
2312 78316 


$ 3,000.00 


$3,000.00 


0.05111% 


$10 





TABLE 1 



The presently available credit may always be uploaded from the EPD as 
5 described above. For example, user may request his/her personal computer to 
create a Credit File at any moment based on the information stored in the IPD. 
Referring to FIG. 15, the user inserts his/her IPD into an IPD reader /writer and 
requests his personal computer to upload purchasing information from the IPD to 
create a credit file (step 1500). At step 1502, the user enters into his PC the intended 

10 amount of purchases (e.g. $1,700.00) and (optionally) the period of time for which 
the credit is to be extended (e.g. 60 days) (i.e. the amount of time after which the 
final payments for the purchases can be made). The user's personal computer 
compares the desired amount of the intended purchase with the available credit at 
all credit lines and selects credit lines where the amount of available credit exceeds 

15 the intended amount of purchase (step 1504). In the example, the amount of 

purchase is $1,700.00 which exceeds the amount available from the second VISA and 
MC credit lines. At step 1506 the user's computer computes and compares financial 
charges based on 60 days of required credit and daily interest rates for the first VISA 
card and OPTIMA card and, possibly late fees (which may be important if the user 

20 may be late with payments). In this example, the OPTIMA card offers lower interest 
charges as well as lower late fees, so the user's computer displays the result of the 
optimization process to the user and activates OPTIMA identification «Card ID» 
=9375 1389 2312 78316 as the « IPD ID» (step 1508). The entire process of 
activation may take place a few hours before the purchasing activity (e.g. in the 

25 morning) or through an ATM machine if the ATM machine has access to the Credit 
File (CF), or through a remote access to user's computer. At the time of purchasing 
the user upon presenting his/her IPD to the merchant's clerk and inserting it into 
IPD's reader /writer simply informs the clerk the credit card being used is OPTIMA 
and the process proceeds as usual. 
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Although this invention has been shown and described with respect to 
exemplary embodiments thereof, it should be understood by those skilled in the art 
that the foregoing and various other changes, omissions, and additions in the form 
and detail thereof may be made therein without departing from the spirit and scope 
of the invention. Accordingly, the present invention has been shown and described 
by way of illustration rather than limitation. 
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WHAT IS CLAIMED IS: 



1. A method of validating service bills, comprising the steps of: 
monitoring service usage of a service user with a service entity by a 

first monitoring subsystem associated with the user; 

determining by means of the first monitoring subsystem at least one 
5 user generated fee value representing the amount due the service entity for service 
usage of the user over a predetermined billing period; 

monitoring service usage of the user by a second monitoring 
subsystem associated with the service entity, the first and second monitoring 
subsystems being distinct from one another; 
10 determining by means of the second monitoring subsystem at least 

one service generated fee value representing the amount due the service entity for 
the service usage of the user over the predetermined billing period; and 

comparing the user and service generated fee values and thereupon 
validating the amount due determined from a predetermined one of the user and 
15 service generated fee values if the user and service generated fee values are within a 
predetermined threshold amount. 

2. A method as defined in claim 1, wherein upon validating the 
amount due, further including the step of authorizing the payment of the amount 
due to the service entity. 



3. A method as defined in claim 1, wherein the service usage is a 
credit/debit transaction including the payment of the amount due by the service 
entity to a merchant on behalf of the user, and the first monitoring subsystem 
includes an electronic card reader/writer associated with and under control of the 

5 user for facilitating the credit/debit transaction. 

4. A method as defined in claim 3, wherein the second monitoring 
subsystem includes an additional electronic card reader /writer associated with and 
under control of a merchant. 
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5. A method as defined in claim 3, further including the step of 
providing usage control restrictions by a primary user to limit usage of other 
secondary users in a debit/credit transaction including at least one of: maximum 
purchase price, type/ class of goods /services, predetermined merchants/ facilities, 

5 validity period, and wherein the step of monitoring service usage includes refusing 
service usage if such usage does not satisfy a control restriction. 

6. A method as defined in claim 3, further including the step of 
downloading discounts from a merchant Web site into an electronic card via the 
electronic card reader /writer, the discounts being available for purchases in a 
debit/credit transaction with predetermined merchants /facilities for predetermined 

5 goods /services. 

7. A method as defined in claim 6, further including the step of 
providing access control to authorized users prior to the step of downloading 
discounts. 

8. A method as defined in claim 1, wherein the steps of monitoring 
service usage is telephone usage. 

9. A method as defined in claim 1, further including the step of 
employing at least one of hash values and digital signatures to confirm the integrity 
of information used to calculate the user generated fee value. 
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10. A system for validating service bills, the system comprising: 

a first monitoring subsystem associated with and under the control of 
a service user for determining at least one user generated fee value associated with 
the amount due a service entity for service usage of the user over a predetermined 
billing period; and 

a second monitoring subsystem communicating with the first 
monitoring subsystem, the second monitoring subsystem being associated with and 
under the control of the service entity for determining at least one service generated 
fee value associated with the amount due the service entity for the service usage of 
the user over the predetermined billing period, one of the first and second 
monitoring subsystems comparing the user and service generated fee values and 
thereupon validating the amount due determined by a predetermined one of the 
user and service generated fee values if the user and service generated fee values are 
within a predetermined threshold amount. 

11. A system as defined in claim 10, wherein one of the first and 
second monitoring subsystems authorizes payment of the amount due upon 
validating the amount due. 

12. A system as defined in claim 10, wherein the first monitoring 
subsystem includes an electronic card reader/ writer associated with and under 
control of the user for monitoring a debit/credit transaction involving payment of 
the amount due by the service entity on behalf of the user. 

13. A system as defined in claim 12, wherein an electronic card used 
with the electronic card reader /writer is one of a smart card and a PCMCIA card. 

14. A system as defined in claim 12, wherein the second monitoring 
subsystem includes a second electronic card reader/ writer associated with and 
under control of the merchant. 
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15. A system as defined in claim 10, wherein the first monitoring 
subs)'stem includes a line monitoring device associated with and under control of 
the user for monitoring telephone usage. 

16. A method of paying utility bills, comprising the steps of: 
monitoring utility usage of a utility user by a first monitoring 

subsystem associated with and under control of the user; 

calculating by means of the first monitoring subsystem at least one 
5 user generated fee value representing the amount due a utility entity for utility 
usage of the user over a predetermined billing period; 

monitoring utility usage of the user by a second monitoring subsystem 
associated with and under control of the utility entity, the first and second 
monitoring subsystems being distinct from one another; 
10 calculating by means of the second monitoring subsystem at least one 

utility generated fee value representing the amount due the utility entity for the 
utility usage of the user over the predetermined billing period; and 

comparing the user and utility generated fee values and thereupon 
authorizing the payment of the amount due determined from a predetermined one 
15 of the user and utility generated fee values if the user and utility generated fee 
values are within a predetermined threshold amount. 

17. A method of paying as defined in claim 16, wherein the utility 
usage to be monitored is telephone usage. 

- 18. A method of paying as defined in claim 16, wherein the step of 
monitoring utility usage by the first monitoring subsystem includes employing a 
line monitoring device. 

19. A method of paying as defined in claim 17, wherein the step of 
monitoring telephone usage includes employing a line monitoring device (LMD) by 
the first monitoring system, the LMD monitoring information including: the identity 
information of the utility entity, the telephone call recipient telephone number, and 
5 the times of day when connection has been established and terminated between the 
telephones of the user and call recipient. 
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20. A method of paying as defined in claim 16, wherein the step of 
calculating by means of the first monitoring subsystem includes executing a 
software algorithm on a computer associated with and under the control of the user. 

21. A method of paying as defined in claim 16, wherein the step of 
comparing includes transferring the utility generated fee value from the second 
monitoring subsystem to the first monitoring subsystem, and performing the 
comparison by means of the first subsystem. 

22. A method of paying as defined in claim 21, wherein the step of 
paying the amount due includes automatically authorizing by means of the first 
monitoring subsystem the electronic transfer of money associated with the amount 
due from a money withdrawal source of the user to a money deposit source of the 

5 utility entity, the amount due determined from a predetermined one of the user and 
utility generated fee values. 

23. A method of paying as defined in claim 16, wherein the step of 
comparing includes transferring the user generated fee value from the first 
monitoring subsystem to the second monitoring subsystem, and performing the 
comparison by means of the second subsystem. 

24. A method of paying as defined in claim 23, wherein the step of 
paying the amount due includes automatically authorizing by means of the second 
monitoring subsystem the electronic transfer of money associated with the amount 
due from a money withdrawal source of the user to a money deposit source of the 

5 utility entity. 

25. A method as defined in claim 16, further including the step of 
employing at least one of a hash value and a digital signature to confirm the 
integrity of information used to calculate the user generated fee value. 
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26. A system for paying utility bills, the system comprising: 

a first monitoring subsystem associated with and under the control of 
a utility user for calculating at least one user generated fee value associated with the 
amount due a utility entity for utility usage of the user over a predetermined billing 
5 period; and 

a second monitoring subsystem communicating with the first 
monitoring subsystem, the second monitoring subsystem being associated with and 
under the control of the utility entity for calculating at least one utility generated fee 
value associated with the amount due the utility entity for the utility usage of the 
10 user over the predetermined billing period, one of the first and second monitoring 
subsystems comparing the user and utility generated fee values and thereupon 
authorizing the payment of the amount due determined from a predetermined one 
of the user and utility generated fee values if the user and utility generated fee 
values are within a predetermined threshold amount. 

27. A system as defined in claim 26, wherein the utility usage to be 
monitored is telephone usage. 

28. A system as defined in claim 26, wherein the first monitoring 
subsystem includes: 

a line monitoring device (LMD) communicating with the utility to be 
monitored for measuring utility usage; and 
5 a computer communicating with the LMD and including means for 

calculating the user generated fee value associated with the amount due the utility 
company. 

29. A system as defined in claim 28, wherein the LMD monitors 
information including: the identity information of the utility entity, the telephone call 
recipient telephone number, and the times of day when connection has been 
established and terminated between the telephones of the user and call recipient. 
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Fig 2LSchematic diagram of the Line Monitoring Device 
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Fig ^ Example of Rates Plan File 



r 



Service Provider (carrier) ID 



Rates Plan ID 



Customer ID/Account Number (optional) 



Hash Value 



Local Rates 



Long Distance Rates 



Area Code 1 :564 



Area Code 2: 575 



Area Code N: 937 



International Rates 



Country l:code33 



Country 2: code 44 



Country M; code 39 



Service Fees ($) 



Taxes (%) 



MCI987765 . [o~2- 



mcil24597765456*r- \ 



dla96754443120037— >£t> 



094671209375654496897747....3275— 



time period 1 
00:00 - 07:00 



rate($) 
0.03 



time period 2 
07:00 - 12:00 



rate($) 
0.05 



time period 3 
12:00-24.00 



rate($) 
0.07 



time period 1 
00:00-06.-00 



iate($) 
0.04 



time period 1 
00:60-14.-00 



rate($) 
0.08 



time period 1 
14:00-24:00 



time period 1 
00:00 - 05:00 



rate{$) 
0.11 



time period 1 
05:00-18:00 



rate($) 
0.15 



03.00 



02.00 



rate($) 
0.07 



rate($) 
0.13 



04.75 



4.5 



no 



time period 1 
18:00 - 24:00 
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Fig. S Example of Connection Record 



Connection Record ED and date 


CR124577432/10-2-1999 


Service Provider(carrier) ID 


MCI987765 


Number dialed 


860-1234567 


Time stamp (beginning connection) 


17-05-35 


Time stamp (end of connection) 


17-11-57 


Hash Value 


98007655444497322777...00999 



-IS 



Fig-6 Example of Activities File 



Activities File ID AF56778900000000 



2GO 



-2^ 



Date: 10-5-1999 



CR 124577432/10-2-1999 



CR124577433/1 0-2-1999 



CR124577434/10-3-1999 



Hash Value 786655545398027272720965864....009745 



16 
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Fig- 7 Example of Billing File (BF) 



r 



Service Provider (carrier) ED 



Customer Account 



Payment Bank Account/Credit Card # cxp date 



Accounting Period 



Digital Signature /algorithm ID 



MCI987765 



dla96754443 120037 



1234 56578 9876 5432 //032003 



10-1-1999 : 10-15-1999 



09987655001236756454//RSA2048 



]?52 2ts4- Local Call^"^ 



Date 



10-2-1999 



10-7-1999 



Number 



860-1234567 



860-7654321 



Time 



07:05:40 



19:57:33 



Total Local Calls Charges ($) 



Duration (pain) 



08:57 



11:45 



1.05 



Date 



10-3-1999 



10-5-1999 



Long Distance Calls 
/-S*7o 



Number 



757-1234567 



575-7654321 



Time 



09:05:40 



21:57:33 



Total Long Distance Calls Charges ($) 



r 



Duration (rnin) 



07:57 



5:45 



1.46 



2 fQ. r ~2.%\ InternationalCalls ^ifft 



Date 



10-3-1999 



10-5-1999 



Number 



33-7531234567 



39-375-7654321 



Time 



14:05:40 



23:57:33 



Total International Calls Charges ($) 



Total Calls Charges ($) 



Fees 



Taxes ($) 



2.00 



1.75 



Total Charges for Accounting Period ($) 



Duration (min) 



17:57 



34:45 



7.10 



9.61 



3.00 



2.54 



27.22 



Charge($) 



0.45 



0.60 



2 SO 



Charge($) 



0.80 



0.66 



r 



^10 



Charge($) 



3.60 



3.50 



4.75 



3.57 



^1 



-2<74 



15 
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FIG £ 



Flow chart of user set-up process 



Receive RPF from utility's web scrver/CDROM/Diskette or 
scan/ key in RPF from paper document 



30 2- 



Vcrify data integrity of RPF using hash value in the RPF and stored hash 
function 




no 



3O0 





yes 






LMD generates symmetric 
encryption key and sends it to PC 








r 




TSB receives symmetric encryption key , prompts user for a password and 
executes password protection of the received key 


1 





end of set up 
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FIG ^5 ^low chart of local accounting process by LP AS 
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3 SO 



Process begins: user dials telephone 



LMD turns on, opens new CR and begins recording of line signals 
LMD time stamps the moment when connection has been established 



User hangs up 

LMD stops recording of line signals 
LMD time stamps the end of connection 
LMD closes Connection Record 
LMD encrypts and stores current AF 




no 



35* 



LMD closes AF 
TSB retrieves AF from LMD and decrypts it 



-jT- 



1^0 



TSB computes charges for the accounting period using RPF and AF files 

and generates BF; 



3 4>2i- 



TSB digitally signs and encrypts summary BF 
TSB displays and prints plain text data on request from the user 



3 4,-1- 



TSB sends signed and encrypted BF to the utility company 
and payment instructions to the user's bank/credit card process 



r 



34>(o 



end of process 



21 
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Fig. fO Flowchart of Billing File audit and reconciliation by Central Revenue Accounting 

System (CRAS) 



4rOO 



Receive BF from LP AS 



Decrypt BF and verify Digital Signature 




no 



investigate 



4or 



Retrieve accounting charges data elements from Customer Invoice File (GIF) and BF and compare 




yes 




initiate dispute resolution process 



14 
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Fig. 1 | Flow chart of discrepancy resolution process by CRAS 



Retrieve accounting charges from BF and CIF and compare them pairwise 




run diagnostic and determine the source(s) and cause of discrepancy 




initiate recovery process 
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Enter user s identification and password and execute a secure communication session with purchasers* or merchants" web site 



500 



Download « ltcmld». «Merchant& Facility ld», «P rice/Disco uni» and «Validi<y» in format ion from purchaser s or merchant 

web site into the user s IPD memory 
Download « ltcmld», «Merchant&Facilityld», «Price/Discount» and «VaIidity»into merchant s computer 




504 



506 



^ 508 



510 



Retrieve « Itemld», «Merchant&FaciliryId», «Price/Discount» and «Validity» from the IPD s memory 

T 



512 



Compare « Itemld», «Merchant&FacUityId» from IPDs memory and « Itemld>*> entered by merchant s clerk and 
«Merchant&Facility» stored in the IPD s reader/writer 



516 



yes 



Mairh'> 



Compute correct «PurchasePrtc«» for the item using 
Nominal Price entered by clerk and «Price/Discount» 



518 520- 




Store « Itemld», «Merchant& Facility I d» and 
Nominal Price in the IPD s memory and terminate 
transaction 



Transfer « ltemld», «Mcrchant&Facilityld», «PurchasePrice», Nominal Price and «Validity» from the IPD 

into merchant s computer 



524 



z 



Merchant s computer compares « tiemld», «Merchant& Facility I d», «PurchascPricc», Nominal Price and 
«Validity»obtained from the IPD with « ltemld». <<Merchant&Facilityld>>, «Price/Discount» and «Validity»stored 




Transaction terminates 
Begin manual investigation 



528 5.10 



Merchant s computer authorizes 
transaction 




FIG- ^ 
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Set-Up: IPD digitally signs and stores authorized user s Identification Information 



Authorized user inserts/interfaces IPD with the IPD s reader/writer 
interfaced with Personal Computer 



User is prompted to enter his/her Identification Information 
(password and Personal Identification Number fingerprint, retina image and the like) 



IPD verifies user s Identification Information 



T 



608 




yes 



612 



610 



600 



602 



.604 



606 



Process terminates 



User enters restrictions on transaction parameters 
(e.g. «lrcmld» = ABC 123 «Merchant&Facilityld» = 765423, «Price/Discounti» less than S75.00 

and«Va!idity» = 1 1/9/00 to 12/9/00) 



IPD stores restrictions on transaction parameters 
«Itemld», «Mcrchant&Faciliryld» > «Price/Discount» and «VaIidity» 



>14 



fx. g. »3 
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User interfaces /inserts IPD into IPD s reader/writer at merchant s facility and enters 
Identification Information 




f 


IPD and IPD s reader writer authenticate each other and IPD verifies user s Identification 

Information 




r 



700 




702 



704 



Clerk enters item-related information 
including «Itemld» and Nominal Price, 
into point-of-sale computer 



710 



712 



714 



716 



Process terminates 
with failed transaction 



K 



706 



708 



Item-related information including «ltemld» and Nominal Price together with 
«Merchant&FaciIityId» is transferred into IPD 



IPD checks restrictions/constraints on transaction parameters «ltemld», 
«M erch an t& Facility I d», «Pricc/Discount» and «Validity» 



Are restrictions satisfied ? 



yes 



Transaction parameters stored in the IPD memory and transaction successfully terminates 



FX G. \^ 
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FIG. 15. for case 6378011 



User inserts IPD into reader/writer and requests creation of Credit File 

(CF) 

User s PC uploads purchasing information from IPD and creates CF 



1500 



User enters into his PC the intended amount of purchase (Amount of 
Purchase) (e.g.S 1,700.00) and expected period of time for which user 
needs credit (Credit Period) (e.g.60 days) 



1502 



User s PC compares Amount of Purchase with available credit at different 
credit lines in CF and selects credit lines with the credit amount exceeding 

Amount of Purchase 



/ 



1504 



User s PC computes financial charges for Credit Period for all credit lines 
selected at the previous step. User s PC evaluates late fees and selects J 
optimal credit line identified by its «Card ID» 



1506 



User s PC displays the result to the user and downloads «Card ID» 
into the IPD as «IPD ID» 



1508 
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